COMMENT ⊗   VALID 00006 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	∂   IMPORTANT!!!  Anyone reading this file please read this page.
C00003 00003	∂16  APR   TVR  	LISP Losder Troubles
C00011 00004	 ∂  LEFAIVRE at RUTG
C00013 00005	 ∂08-Jan-77  1536	FTP:BOSACK at DEC-MARLBORO	LISP 1.6
C00015 00006	∂28-Jan-77  1533	RWW  
C00016 ENDMK
C⊗;
∂   IMPORTANT!!!  Anyone reading this file please read this page.
This file is currently in use by RWW and is used by him to deposit
information and messages that he considers relevant to future LISP 
maintainance.   The file should not be deleated for any reason as
doing so will help destroy an automatic updating system of mine.
∂16  APR   TVR  	LISP Losder Troubles
To:   RWW
CC:   LES, REG   
Facts:
1.  I have not been able to generate a good LISP loader from any
    LOADER.MAC's found on DART tapes since the modification at
    sometime near to 11-Jan-74.
2.  There was found one LISP loader on [1,3] which works correctly
    with a LIB40 from 31-Oct-73.
3.  The LISP loader most recently generate dies substantially more
    often when the system is loaded.  In fact, it is difficult to
    make it fail when there is no one else on the system.  When
    the system is heavily loaded, it is difficult to make it
    succeed.
4.  It dies by clobbering 203 words on LISP free storage area,
    which starts at the same point for each loader i have tried,
    although the address of beginning of clobberage varies with
    differing LISP loaders.
5.  In the most recent version of LOADER.MAC[CSP,SYS], the
    address of clobbering is at the symbol BUF1, which is of
    size 2*203 and is commented to be "LOAD BUFFER AREA". The
    clobberage seems to look like a REL file.
6.  The problem was first observed around the time the HISEG
    stuff was put up.
7.  IL goes thru the following states when loading something

     __________		 __________	      __________	
    | Low LISP |	| LOADER   |	     | Low LISP |
    |__________|	|	   |	     |__________|
    | Free Stg |	|	   |	     | Free Stg	|
    |          |	|----------|	     |		|
    |          |	|	   |	     |		|
    |          |	|          |	     |	        |
    |----------|	|----------|	     |----------|
    |  Symbol  |	| Copy of  |	     | New code |
    |  tsble   |	| Low LISP |	     |----------|
    |__________|	|   etc.   |	     |		|
			|----------|	     |----------|
			|__________|	     |  Symbol	|
		        |  Symbol  |	     |  table	|
		        |  tsble   |	     |__________|
			|__________|	
     Before		  During		After

8.  From searching the source, the LOADER does not appear a
    CLOSE or RELEAS of the channel which uses BUF1 before
    returning to LISP.

Suspicions:
   Perhaps some bizaar timing race is happening whereby
between the time Low LISP is BLT'ed back and the time it
does a RESET or whatever, the system is reads in another
buffer from the incompletely read LIB40 (not read to EOF
because one doesn't load from all of it) trying to stay
ahead of the user.  It may have never been discovered in
the past because we have recently become more disk-bound
than before, or perhaps the system has been modified in
past few monthes that affects that.

What's next:
   On Monday afternoon, i will try adding a RELEAS to the
LOADER to see if that fixes it.  I also will try a fix to
the 'missing symbol' bug.
   I am interested to know whether this was caused by a
change in the system or just a bug which came alive by an
environmental change.

			Sincerely,
			   Tovar

P.S. Please forward this to any interested LISP sufferers.

17 MAR   DSB  
Suggested addition to IL: Make <ESC>I act like <CALL> REE B (ie break
whatever is going on and enter errorx.)

3  FEB   TVR  	LISP Loader interface   
To:   REM, RWW    
I found out why the new version of the LISP loader for IL didn't seem to
work right.  The problem was that it did work right... and IL had been
kludged by DWP to compensate for a LOADER bug!  However, i was unable to
debug the changes properly due to a bug in the system and i'll try again
tomorrow (or when i'm get back from Berkeley).   --- Tovar

22 DEC TVR  
To:   RWW, REG    
Reassembling it fixed the bug, after locating a missing '>' in LOADER.MAC[CSP,SYS].
Old version is ILLOD.OLD if you need to roll back.  Probably can be deleted if no
trouble in a next month.   --- Tovar

13 DEC REM
(1) The instructions for loading fortran arithmetic package into IL
is incorrect.  A year or two ago I discovered that IARITH rather than
ARITH is the correct file name (*.lsp and *.rel).
(2) More recently I discovered that it no longer works at all.
Do you know how to load the fortran arithmetic functions into IL now?

10 DEC RAE
IL COMPILER BUG    

(DE TEST3 (PSX PSA)  (COND((NOT (EVAL PSX))(SETQ PSA 4))))

ILISP
(LAP TEST3 SUBR) 
       (PUSH P 1) 
       (CALL 1 (E *EVAL) S) 


LISP1.6 COMPILER

(LAP TEST3 SUBR) 
	(PUSH P 1) 
	(CALL 1 (E *EVAL)) 
	(JUMPN 1 TAG2) 
	(MOVEI 1 (QUOTE 4)) 
	(JRST 0 TAG1) 
TAG2 	(MOVEI 1 (QUOTE NIL)) 
TAG1 	(SUB P (C 0 0 1 1)) 
	(POPJ P) 
	NIL 
6 DEC REM
OK, there is a definite bug in the initialization of IL.
DO THE FOLLOWING:
(1) R IL<CR> (CAR 1)<CR>
  you get ill mem ref trap to monitor because IL hadn't yet enabled user int.
(2) R IL<CR> ↑C S<CR> (CAR 1)<CR>
  you get ill mem ref trapping to break package as it should.

 ∂  LEFAIVRE at RUTG

29 JUL
 I am trying to locate someone on the net who has the sources of the
 latest version of UCI LISP which runs under the standard DEC monitor.
 I wonder if you might have them at SAIL.  If so, would it be
 possible for me to copy them over here to Rutgers?  If not, do you know
 who might have them (I'd like to exhaust possible sources on the net
 before I start hassling with tapes).  I'd also like to locate the
 necessary files to bootstrap the various AI systems which have been
 translated into UCI LISP, e.g., MICROPLANNER, MLISP2, and whatever else
 is available (SHRDLU, CONNIVER, ...?).
 Let me thank you in advance for any help you can give me on this matter.
 -Rick LeFaivre

 ∂08-Jan-77  1536	FTP:BOSACK at DEC-MARLBORO	LISP 1.6
Date:  8 Jan 1977 1834-EST
From: BOSACK at DEC-MARLBORO
Subject: LISP 1.6
To:   RWW at SAIL

I WAS POINTED AT YOU BY RPH->JAM->RWW AS THE KEEPER OF LISPISH THINGS.

DO YOU RECALL HEARING OF ANY BUGS IS THE DECUS LISP 1.6 HAVING TO DO
WITH STRANGE NONWORKINGNESS GIVEN > 2**18 FREE STG CELLS? WE ARE USING
SEVERAL SYMBOLIC ALGEBRA PACKAGES BASED ON DECUS LISP 1.6 AND I WAS
COMPLAINED AT ABOUT THEM FALLING OVER IN TOO MUCH CORE. ANY INFO
APPRECIATED. IF YOUR HOST TABLES HAVENT BEEN UPDATED NOW THAT WE
ADMIT TO BEING ON THE NET, DEC IS HOST 37.
REGARDS,
LB
-------

LISP 1.6 almost certainly will not work with large amounts of free 
storage.  There are several reasons not the least of which is that
pointers are halfwords also the garbage collector uses a bit table
which is not big enough.  Also inums (the small integer hack) take
up some of that address space.   Don't know how you've been bitten
but I don't see how to avoid this particular problem in any simple
way.  sorry for the delay in answering.  If you have further questions
I'll be glad to try to be more detailed in my answers.
				richard weyhrauch   rww@su-ai

∂28-Jan-77  1533	RWW  
 ∂22-SEP-76  1410	100  : Connie Stanley    
A Mr. Paul Treece from the Colorado School of Mines Computing Center called
today (9/22 @ 2:00P) regarding LISP and INTERLISP.  His number is
303-279-0300, ext. 435.  Please give him a call.